This is a monthly segment in which Versant Object Technology reviews some aspect of object databases. This month's tip focuses on savepoints.

USING SAVEPOINTS

There are times when people like to use a Graphical User Interface (GUI) as a front end to an object database application to manipulate information via screens, panels, and dialog boxes. In such cases, the need sometimes arises for users to fill out multiple forms with data.

Each screen can be seen as a modification of some set of objects. What happens when the user is within, say, her fourth screen of input and realizes that what was done should be undone so that she can go back to her original second screen? All the work that was done in screens three and four should be undone in the application at this point. How is this accomplished in the context of a Versant ODBMS application?

One solution is to use the concept of surrounding a code region in a transaction with a savepoint. This records a marker for the current short transaction to serve as a basis for a partial rollback. At this point a new set of statements can be written (e.g., call code to bring up another screen in a GUI).

If the user decides to undo her changes in the GUI application, the undosavepoint method could be called on the transaction manager to rollback any changes to the last savepoint. Savepoints can be nested, which is great for applications with nested GUI semantics. An undosavepoint which does not have a matching savepoint that came before it will roll back the transaction state to a previous commit point.

This feature is one of several that can be used in a sophisticated transaction model in the context of an ODBMS. In this manner, the semantics of the GUI application can be modelled within the portion of the application which manipulates the database.

by Nimish Doshi

[ What's New | Products | Partners | Tech Support | About Us | Employment | Contact Us | Search | Home ]
[ C++ Solutions | SmallTalk Solutions | Internet Solutions ]